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REPLY BRIEF 

This is a Reply Brief in an appeal from the rejection set forth in the Final Rejection dated 
July 3, 2007, (hereinafter "the Final Rejection") in the above-identified application. Appellant 
respectfully submits that the rejections in the Final Rejection which were not withdrawn in the 
Examiner's Answer dated February 21, 2008, were made in error, and that the rejections should 
be reversed for the reasons set forth in the Appeal Brief filed on January 2, 2008, as supplemented 
by the reasons set forth herein in response to new issues raised by the Examiner. 

1. The Rejection of Claims M0 Under 35 U.S.C. §102(b) as Anticipated 
by U.S. Patent no. 5,909,545 (Frese) 

A. Claim 1 

On pages 14-15 of the Examiner's Answer, the Examiner argues for the first time that, 
. .the system [not the server] is required to be intentionally and specifically made to enable the 
server to control the client's display." (emphasis original) See page 14, last line to page 15, first 
line, of the Examiner's Answer. The Examiner continually places emphasis on the fact that the 
claims require that the "system" be configured to enable the server to control the display of the 
client computer, but still fails to show that Frese meets this claim limitation. 

The Examiner then paraphrases the requirements of claim 1 stating that, "... (1) the server 
and the client need to be connected via some network and (2) the server needs to be capable of 
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being provided with means for controlling the display of the client, as described in the Final 
Rejection." (emphasis added) See page 15, lines 2-4 of the Examiner's Answer. However, this 
paraphrase of the claim language is incorrect since it uses the terminology "capable of being 
provided with." In actuality, the claim requires that the system is "configured to enable the server 
to control the client's display." Also, the Examiner does not explain how a server that is capable 
of being provided with a means for controlling the display, but has not yet been provided with 
such a means (e.g. as in Frese), would be intentionally and specifically made to act to control the 
display of the local client computer. In fact, until the actual means was provided, the server 
would not be configured to control the display on a client computer. This demonstrates the error 
in the Examiner's paraphrase of the current claim language. 

On page 15, in Section A.l.b of the Examiner's Answer, the Examiner correctly identifies 
a typographical error in the Appeal Brief for this application. The Appeal Brief at page 10, lines 
1-2 incorrectly stated that "the client computer" must be configured to enable the server to control 
the display on the client computer, when, in fact, the Appeal Brief should have stated that the 
"system" must be configured to enable the server to control the display on the client computer. 
However, this typographical error does not alter the fact that the Examiner has not identified any 
structure, means, hardware or software in Frese that meets this limitation of claim 1. 

The Examiner has conceded that the language, "configured to enable" requires that the 
system be intentionally and specifically made to act in a certain way. It follows from this that 
claim 1 clearly requires that for the server to be configured to enable control of the display on the 
client computer, the system must include some hardware or software for intentionally and 
specifically making the server control the display of the local client computer. (See page 11, lines 
3-6 of the specification). The Examiner again makes a conclusory statement that Frese clearly 
discloses this feature of claim 1, but fails to identify the specific hardware or software disclosed in 
Frese which meets this claim limitation, instead relying for this purpose on an applet tag 
contained in an HTML document that is transmitted from the internet to the client computer via 
the server. The Examiner has also not met his burden of proving that the system of Frese includes 
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some means for enabling the server of Frese to control the display on the screen of a client 
computer. In fact, Frese does not disclose this feature of claim 1 and thus claim 1 is novel over 
Frese for at least this reason. 

In Section A.l.c on page 16 of the Examiner's Answer, the Examiner argues that RDM 18 
of Frese is "means for locally running at least one further application (18), wherein the system 
comprises means for controlling the locally run applications (18)." (emphasis original). However, 
this argument ignores the remainder of the claim language that is part of this claim limitation 
requiring, "means for controlling the locally run applications through the user interface provided 
by the server ." RDM 1 8 of Frese is not a means for controlling the locally run applications 
through a user interface provided by the server since RDM 18 itself provides the user interface of 
Frese when it is run on the client computer. Thus, Frese does the opposite of what is claimed in 
the present claim 1, namely, controls the display of the local client computer using the RDM 18 
executed on the client computer rather than controlling the display of the local client computer 
through a user interface provided by the server. See col. 9, line 63 to col. 10, line 4 of Frese. 
Therefore, the client computer of Frese is not configured to enable the server to control the 
display as required by claim 1 but rather, the opposite is true, the client computer of Frese is 
configured to enable the client computer to control the display of Frese. 

In Section A.l.d of the Examiner's Answer, the Examiner concludes that, "Because the 
server provides the applet tags and their parameters that the client is able to select, the server 
ultimately controls the look and feel of the applet that is run by the client." See page 17, last 
sentence of Section A. 1 .d of the Examiner's Answer. The Examiner admits that the RDM 1 8 is 
executed on the local (client) computer and thus it is the client computer that controls the display 
since it is the client computer that executes the RDM 18 that controls the display. The device that 
provides the applet to the client computer, however, does not control anything. In this instance, 
the server merely transmits the executable RDM 1 8 to the client computer, but does not control 
the display of the client computer. Transmitting an executable program for providing the user 
interface is not control of the user interface as required by claim 1 of the pr esent application. 
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In Section A.l .e of the Examiner's Answer, the Examiner concedes that the server does 
not store the HTML documents but now argues that, "... the server does not actually need to store 
the HTML documents in order to meet the claim. Frese' s server clearly provides the HTML 
documents to the client and therefore "controls" the display as described above." The applet tag 
of the HTML document is used to select which RDM 18 is to be transmitted to the local computer 
for execution on the local computer. Thus, the Examiner admits that the selection of which RDM 
1 8 is to be transmitted to the local computer is based on an HTML document that is not stored on 
the server of Frese. Thus, the server of Frese does not even store the information used to select 
which RDM 18 is to be transmitted. All the server of Frese does is transmit an executable RDM 
18 selected by the client computer based on the information contained in the HTML document 
about the properties of the client computer. This is not the same as "controlling" the display of 
the client computer through a user interface provided by the server, as required by the claims. 

In Section A.l.f of the Examiner's Answer, the Examiner incorrectly characterizes the 
broadest reasonable interpretation of the term, "content" to mean, "... any information such as 
text, data, or graphics displayed by the RDM applet 18. The RDM applet's application window 
itself can arguably be considered graphics." See page 18, Section A.l.f of the Examiner's 
Answer. This interpretation of the term, "content" is clearly incorrect since claim 1 of the present 
application requires the presence of both a user interface and contents generated locally on the 
client computer. The Examiner's interpretation of "content" clearly includes aspects of the user 
interface and thus is not a reasonable interpretation of the term, "content" in the context of claim 1 
of the present application. This is because claim 1 already specifies a user interface and thus 
"content" as claimed in claim 1 must be something different than the user interface. 

The Examiner has already admitted that the user interface of Frese is generated by the 
RDM 18 at page 3, lines 20-21 of the Final Rejection. Thus it is improper to rely on the RDM's 
application window as being content when, in fact, the RDM's application window is the user 
interface of Frese. The interrogation interface provided by RDM 18 of Frese relied on by the 
Examiner is also part of the user interface of Frese and the Examiner has not shown that the 
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interrogation interface displays any content generated on the local client computer. Rather, the 
interrogation interface of Frese appears to be just a user interface without locally generated 
content. Thus, Frese does not teach that the server is enabled to control the display on a client 
computer of a screen area having contents generated locally on the client computer, as required by 
claim 1 . 

In Section A.l.g of the Examiner's Answer, the Examiner admits that Ambler does not 
show a web page that controls applications. See page 19 of the Examiner's Answer. Thus, the 
user interface of Ambler is a completely different type of user interface than those referred to in 
claim 1 of the present application since claim 1 requires that the user interface can be used to 
control applications. Thus, even if the web page of Frese were a user interface as the Examiner 
suggests, Frese does not disclose that such web pages can be used to control applications on a 
computer. Rather, at best the web page of Frese can be used to select an application for execution 
by activating the applet tag field of the HTML document (web page) of Frese. See col. 7, lines 
41-44 of Frese. However, once the application has been selected, RDM 18 is transmitted to the 
local client computer and executed to provide the user interface. See col. 6, lines 61-64 of Frese. 
Further, contrary to the Examiner's position in the Final Rejection, Ambler does not show that the 
reference to a "web page" in Frese, implicitly discloses a user interface that can be used to control 
applications since even Ambler does not disclose such a web page as the Examiner has admitted 
in the Examiner's Answer. 

B. Claim 4 

With respect to claim 4, the Examiner argues in Section A.2.a of the Examiner's Answer 
that because the HTML documents of Frese describe the application programs available for 
demonstration (col. 7, lines 34-35 of Frese), and can be viewed on the client computer, this 
provides the means 13, 14, 15 for presenting an overview of available applications installed on the 
server 1 and on the client computer 5 through the user interface, required by claim 4. However, 
Frese does not appear to disclose that the application programs available for demonstration 
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described in the HTML documents of Frese include applications installed on the client computer . 
Thus, Frese still does not meet this limitation of claim 4 of the present application. 



C. Claim 6 

With respect to claim 6, the Examiner argues in Section A.3.a of the Examiner's Answer 
that browser 30 of Frese is the claimed means for generating a merged local client screen. A 
merged local client screen 16, as claimed in claim 6, is a client screen displayed on the client 
computer 5 which merges the local client screen area 9 of Figure 2 A with the central application 
screen area 10 of Figure 2 A of the present application. See page 7, lines 24-27 of the 
specification. The Examiner alleges that the browser 30 of Frese meets this limitation. However, 
Frese does not disclose a local client screen area, as claimed, since claim 1, from which claim 6 
depends, requires that the local client screen area display content generated on the local computer. 
This feature of claim 1 is not disclosed by Frese, as discussed above, and thus Frese cannot 
disclose a merged local client screen since Frese is missing a component of a merged local client 
screen, namely the local client screen area that displays content generated on the local computer. 
The same arguments apply to the Examiner's comments in relation to claims 7-9 found in 
Sections A.4.a-A.5.a of the Examiner's Answer. 

Accordingly, reversal of the rejections of claims, 4 and 6-9 for these additional reasons is 
requested. 

2. The Rejection of Claim 18 Under 35 U.S.C. §102(b) as Anticipated 
by U.S. Patent no. 5,909,545 (Frese) 

Claim 18 requires among other limitations, that the server control the display on a screen 
of the display device of a screen area having contents generated locally on the client computer. 
The Examiner takes the position that server 20 of Frese controls the display of a screen area 
having contents generated locally on the client computer as required by claim 18 by specifying 
the parameters of RDM 18. This is incorrect. 
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In Section A.6.a of the Examiner's Answer, the Examiner argues that, "Just because user 
system 16 controls some aspect of RDM applet 18 does not mean that server 20 does not control 
any aspect of RDM applet 18." The problem with the Examiner's position is that the Examiner 
bears the burden of proving that Frese discloses all elements of claim 18 in support of the 
rejection under 35 U.S.C. 102(b). The Examiner's reasoning does not prove that the server 
controls any aspect of RDM 18. The absence of a statement in Frese that the server 20 does not 
control RDM 18 does not prove that the server 20 of Frese controls RDM 18, as would be 
required to meet the Examiner's burden of proof in support of the rejection. The fact that Frese 
discloses that user system 16 executes RDM 18, clearly does not prove that the server 20 controls 
an aspect of RDM 18. In fact, as discussed above, RDM 18 is merely transmitted by the server to 
the client computer for execution in the system of Frese and the server does not control the RDM 
1 8. Thus, the Examiner has not met his burden of proving that this limitation of claim 18 is 
disclosed in Frese. 

In Section A.6.b of the Examiner's Answer, the Examiner takes the position that Frese 
clearly shows that the HTML document received from the server (col. 7, lines 46-55 of Frese) 
specifies RDM 18's parameters. First, the HTML document of Frese does not specify RDM 18's 
parameters, but rather, specifies parameters used to select RDM 18. See col. 10, lines 5-14 of 
Frese. In fact, Frese teaches that specific system parameters are not required in HTML document 
18 since they are provided by browser 30. See col. 10, lines 11-14 of Frese. 

Moreover, the fact that the server transmits an HTML document to a client computer 
specifying information for selecting particular RDM 18 for transmission to the client computer is 
not sufficient to show that the server of Frese controls the display on the client computer. Mere 
transmission of information used to select the RDM 18 application that runs the user interface is 
not "control." Further, Frese does not indicate that the HTML document is generated by the server 
or even that it is stored on the server. Rather, the HTML document of Frese comes from the 
internet, hence the reason that it is an HTML document in the first place. See col. 7, lines 28-3 1 
of Frese. Therefore, the information contained in the HTML document used to select RDM 18 
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are not generated by, or stored on the server, but rather come from the internet. Thus, for this 
additional reason, the server clearly does not control the display on a screen of the display device 
of a screen area having contents generated locally on the client computer, as required by claim 18. 

In Section A.6.C of the Examiner's Answer, the Examiner again incorrectly defines 
"content" as including aspects of the user interface. This error was addressed above in the 
discussion of Section A.l.f of the Examiner's Answer. Since claim 18 also specifies both a "user 
interface" and "contents generated locally on the client computer" the same analysis as above, 
applies to claim 18 and thus the Examiner's position is clearly incorrect since it is the user 
interface that is generated by RDM 1 8 and not "content." 

3. The Rejection of Claim 19 Under 35 U.S.C. §102(b) as Anticipated 
by U.S. Patent no. 5,909,545 (Frese) 

In Section A.7.a of the Examiner's Answer, the Examiner argues that, "Frese teaches a 
computer program (browser 30) that, when run on a computer (user system 16), causes the 
computer (user system 16) to accept a user interface (web page) provided by a server (RAS 20) 
for controlling the locally run applications (applets 18)," citing Frese Fig. 1 and col. 6, line 39 to 
col. 8, line 50. The problem with this analysis is that in the system of Frese, the web page (HTML 
document) does not control RDM 18 as the Examiner suggests. Rather, the applet tag of the 
HTML document specifies certain parameters used to select which RDM 1 8 will be provided to 
the local computer for execution on the local computer and does not control the display 
parameters as the Examiner suggests (see col. 10, lines 5-14 of Frese). The RDM 18 of Frese 
controls the display. See col. 6, lines 61-64 of Frese. Accordingly, this argument of the Examiner 
is incorrect for this reason. 

The arguments made by the Examiner in Section A.7.b of the Examiner's Answer have 
been fully addressed above in the discussion of Section A.6.a of the Examiner's Answer and the 
same reasoning applies to claim 19 as is given above. 



DOCKET NO.: DVME-1018US PATENT 

The arguments made by the Examiner in Section A.7.C of the Examiner's Answer have 
been fully addressed above in the discussion of Section A.7.a of the Examiner's Answer and the 
same reasoning applies to claim 19 as is given above. 

In Section A.7.d of the Examiner's Answer, the Examiner argues that since the server of 
Frese transmits an HTML document containing an applet tag used to select RDM 18 from the 
internet to the client computer, the server of Frese controls the user interface of the client 
computer. This is clearly incorrect for the reasons discussed above in relation to Section A.7.a of 
the Examiner's Answer. 

Accordingly, for the reasons given in the Appeal Brief and the additional reasons 
presented above, the Applicant maintains that the Examiner's rejection of claims 1-10 and 18-19 
under 35 U.S.C. 102(b) over Frese should be reversed. 

4. The Rejection of Claims 1-10 under 35 U.S.C. 103(a) over U.S. Patent no. 
5,613,090 (Willems) 

In Section B beginning on page 24 of the Examiner's Answer, the Examiner takes the 
position that, "Willems does not teach away from modifying prior art figure 8 to enable to 
window manager to (1) control a client's locally run applications and (2) run window manager 
2100 and X server 102 on the same machine." See page 24, Section B, lines 1 1-13 of the 
Examiner's Answer,. The Examiner admits that the prior art embodiment of Fig. 8 of Willems 
which forms the starting point for the Examiner's obviousness analysis lacks two elements of 
claim 1, namely: (1) controlling locally run applications through the user interface provided by 
the server (page 14 of the Final Rejection), and (2) means for locally running at least one 
application (page 14 of the Final Rejection). Thus, to arrive at the subject matter of claim 1 of the 
present application starting from Figure 8 of Willems, the skilled person would have to: (1) 
choose to locate window manager 100 on X server 102, and (2) provide means for locally running 
at least one application. 
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The Examiner supports his position with the new argument in Section B.l .a of the 
Examiner's Answer that, . .the mere fact that the motivation of reducing front-end code lead [sic 
- leads] Willems to disclose the invention of figure 9 does not establish that one of ordinary skill 
in the art would consider the invention of figure 9 to be the only way of achieving this result. It 
does not even establish that Willems himself did not consider locating the window manager 100 
and X server 102 on the same machine. Indeed, Willems could very well have considered this 
modification and found it to be so obvious as to not warrant disclosure." See page 25, second 
paragraph of Section B.l .a of the Examiner's Answer. 

The Examiner's position is pure speculation and not supported by the disclosure of 
Willems. The Examiner bears the burden of proof and the fact that Willems does not disclose the 
modification suggested by the Examiner but instead modifies the embodiment of Figure 8 to 
arrive at the embodiment of Figure 9, something other than the invention claimed in the present 
application, clearly establishes that Willems teaches away from the present invention by showing 
the skilled person to modify Figure 8 to arrive at Figure 9, which is not the present invention. The 
Examiner is trying to rely on elements that are not disclosed in Willems and speculation in 
support of the rejection. This is clearly improper. 

The Examiner argues in Section B. 1 .b of the Examiner's Answer that, "... combining the 
remote window manager 100 and X server 102 would clearly decrease network traffic between 
these two components because there would no longer be a network separating these components." 
See the sentence bridging pages 25-26 of the Examiner's Answer. There are several problems 
with this allegation made by the Examiner. First, Willems does not disclose that combining X 
server 102 with window manager 100 would decrease network traffic and thus this conclusion is 
pure speculation by the Examiner. Second, Willems does not even disclose whether it is possible 
to combine X server 102 and window manager 100 as the Examiner suggests. This is a non- 
trivial exercise when one considers that the system contemplated by Willems maintains multiple 
simultaneous connections to multiple Windows front ends 14 each of which will have its own 
network connection and Windows manager 100. See col. 4, lines 22-27 and lines 45-53 of 
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Willems. Thus, to implement the suggestion of the Examiner, multiple Window managers 100 
would have to be run on X server 102, one for each Windows front end 14. Willems does not 
disclose that X server 102 would be capable of running multiple Window managers 100 without 
taking a serious performance hit. Thus, a skilled person would have no reason to expect that this 
embodiment would be possible or advantageous. 

Finally, and most importantly, one of the two stated goals of Willems is to reduce the 
front-end code required for the Windows front end 14. Willems only teaches that this goal can be 
accomplished by locating window manager 100 locally. Thus, the Examiner's proposed 
modification of Figure 8 would not reduce the front-end code since it would not locate window 
manager 100 locally and thus would not accomplish one of the stated goals of Willems. 

The Examiner argues that Willems provides a clear motivation to combine window 
manager 100 and X server 102 where Willems states that, "a performance hit is taken because of 
additional traffic between the window manager 100 and the 'X Windows' application 18, 20 and 
22 and between the window manager 200 and the X server 102." However, the Examiner again 
ignores the fact that Willems uses this stated motivation as a reason to implement the embodiment 
of Figure 9 and not the configuration proposed by the Examiner, thereby teaching away from the 
present invention. 

The Examiner argues in Section B.l.c of the Examiner's Answer that, "In order to 
'provide express motivation not to make the Examiner's proposed change' Willems would need 
to actually mention the Examiner's proposed change. See second paragraph of Section B.l.c of 
the Examiner's Answer. The applicant disagrees. Rather, Willems teaches that the front-end 
code required for Windows front end 14 can be reduced by running window manager 100 locally. 
This is a clear teaching not to make the Examiner's proposed change since the Examiner's 
proposed change would not achieve this stated goal of Willems to reduce the front-end code 
required for Windows front end 14 since the Examiner's proposed embodiment would not run 
both window manager 100 locally. Thus, since the Examiner's proposed embodiment lacks one of 
the key advantages sought by Willems, Willems teaches a skilled person to avoid the Examiner's 
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proposed embodiment and implement the embodiment of Figure 9 since the Figure 9 embodiment 
achieves the key advantage of reducing front-end code. 

In Section B. 1 .d of the Examiner's Answer, the Examiner alleges that providing means on 
the client computer for locally running at least one further application will reduce the amount of 
front-end code required for Windows front end 14. There is no support in Willems for this 
conclusion. The Examiner concedes this on page 29, lines 6-8 of Section B.l .g of the Examiner's 
Answer. Willems only teaches that running window manager 100 locally will reduce the amount 
of front-end code required. There is no indication in Willems that running an additional 
application locally will further reduce the amount of front-end code required in the system of 
Willems. This is pure speculation on the part of the Examiner and should be disregarded. 
Moreover, the Examiner agrees that running at least one further application locally will increase 
network traffic. Thus, since the skilled person knows that running at least one further application 
locally in the Examiner's proposed configuration will increase network traffic but does not know 
the impact of this on the amount of front-end code required, the skilled person would be led not to 
implement this feature in combination with locating window manager 100 on X server 102 as the 
Examiner suggests since only a detrimental effect is expected, i.e. an increase in network traffic. 
Note that this detrimental effect is also avoided by implementing the embodiment of Figure 9 of 
Willems in combination with an additional locally run application, thereby providing a further 
reason for the skilled person to adopt the configuration of Figure 9 of Willems rather than the 
Examiner's proposed configuration. 

In Section B.l.e of the Examiner's Answer, the Examiner makes essentially the same 
argument that was made in Section A. 1 .a of the Examiner's Answer. This argument has been 
addressed in detail above in relation to Section A.l.A of the Examiner's Answer. 

In Section B.l.e of the Examiner's Answer, the Examiner further argues that whether the 
X server 102 of Willems is enabled to control a display on the client computer of a screen area 
having contents generated locally on the client computer is moot because, "Willems would 
obviate [sic] the claims even if they actually required the server to control the display on a screen 
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area having contents generated locally on the client computer because enabling the window 
manager to control a client's locally run applications would enable it to control the display on a 
screen area of a screen area having contents generated locally on the client computer." See page 
28, second paragraph, Section B .1 .e of the Examiner's Answer. This statement does not make 
sense since Willems does not disclose that window manager 100 can be used to control locally 
run applications. Rather, Willems discloses that window manager 100 can be used to control X 
Windows applications 18, 20 and 22. See col. 14, lines 1-2 of Willems. X Windows applications 
18, 20 and 22 are not locally run applications but instead are remotely run applications, as can be 
seen from Figure 9 and col. 13, lines 66-67 of Willems. Thus, this statement by the Examiner 
appears to be incorrect. 

The arguments made in Section B.l.f of the Examiner's answer have been fully addressed 
above in respect to similar arguments made in Section B.l.b of the Examiner's Answer. 

In Section B.l .g of the Examiner's Answer, the Examiner again discusses enabling the 
window manager 100 of Willems to control locally run applications. However, as discussed above 
in relation to Section B.l .e of the Examiner's Answer, Willems does not teach that the window 
manager 100 can be enabled to control locally run applications, but rather only teaches use of 
window manager 100 to control remotely run applications. 

The Examiner further alleges in Section B.l.g that, "One of ordinary skill in the art would 
readily recognize that enabling the remote window manager 100 to control locally run 
applications would clearly enable the system designer to eliminate code at the client side." See 
page 29, Section B.l .g, last sentence. This statement is pure speculation and is not supported by 
any evidence, including the disclosure of Willems since Willems discloses enabling window 
manager 100 to control remote applications but not local applications, as discussed above in 
relation to Section B.l.e of the Examiner's Answer. Further, the Examiner has not indicated what 
code could be eliminated on the client side nor has the Examiner indicated why such code could 
be eliminated by the proposed arrangement of features. Willems actually teaches that front-end 
code can be eliminated by making all window management local. See col. 14, lines 1-2 of 
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Willems. There is no teaching in Willems that window manager 100 can or should control locally 
run applications or that front-end code could be reduced by doing so. 



5. The Rejection of Claim 18 under 35 U.S.C. 103(a) over U.S. Patent no. 
5,613,090 (Willems) 

The argument made by the Examiner in Section B.2.a of the Examiner's Answer has been 
fully addressed above in relation to the similar arguments made by the Examiner in Section B.l. a 
of the Examiner's Answer. 

The argument made by the Examiner in Section B.2.b of the Examiner's Answer has been 
fully addressed above in relation to the similar arguments made by the Examiner in Section B.l .b 
of the Examiner's Answer. 

6. The Rejection of Claim 19 under 35 U.S.C. 103(a) over U.S. Patent no. 
5,613,090 (Willems) 

The argument made by the Examiner in Section B.3.a of the Examiner's Answer has been 
fully addressed above in relation to the similar arguments made by the Examiner in Sections B.l. a 
and B.l.c of the Examiner's Answer. 

The arguments made by the Examiner in Sections B.3.b and B.3.C of the Examiner's 
Answer have all been made before and are fully addressed in the Appeal Brief and Sections B.La- 
B.l.c above. 

The arguments made by the Examiner in Section B.3.d and B.3.e of the Examiner's 
Answer have been addressed in detail above in relation to the substantially similar arguments 
made in Sections B.l.a-B.l.d above. 
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PATENT 



Accordingly, for the reasons given in the Appeal Brief and the additional reasons 
presented above, the Applicant maintains that the Examiner's rejection of claims 1-10 and 18-19 
under 35 U.S.C. 103(a) over Willems should be reversed. 
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